Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For curve25519-dalek, overflow doesn't happen in field AddAssign for a collaborative prover #4

Open
wants to merge 5 commits into
base: risczero
Choose a base branch
from

Conversation

weikengchen
Copy link

@weikengchen weikengchen commented Feb 26, 2024

This PR propose a different way to add two numbers for ed25519's Fq elements.

We observe that ed25519's Fq is smaller than 2^{255}. If the prover is collaborative, all the "denormalized" numbers should be small than 2^{255}, overflow should never happen. So, it is safe to enforce that the carry7.0 is zero.

With the assumption that carry7.0 is zero, we can use the mul_mod syscall to reduce it to be smaller than the modulus. For a collaborative prover, it can make sure that the result is smaller than 2^{255}. If a prover is not collaborative, the number may be higher---this would not be disastrous because if it doesn't cause an overflow, it is okay, if it causes an overflow, the code would detect and refuse.

This change reduces the number of cycles caused by AddAssign.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants